I've gone ahead and overhauled the sampling API in a manner which resolves your third review comment, but which is very different from what came before. In my latest version, LlamaSamplers can be defined as either a chain or a single sampler as determined by LlamaSamplerParams, which is an enum struct that contains all parameters needed to construct a LlamaSampler. I used this to factor out all of the LlamaSampler::add_ and LlamaTokenDataArray::sample_ methods in favor of specifying which sampler to use using the enum. This deduplicates a lot of code and does not make the interface much more clunky than it was.

If you think that this API is too far from the raw API or complicates things too much, let me know.

I don't mind the new API. I weakly preferred the "closer to direct calls" one.

I think a LlamaSampler struct with a collection of factory functions would be preferable to the params + enum approach. This would also allow different lifetime signatures for different samplers (have most return LlamaSampler<'static> if it owns everything, or LlamaSampler<'a> if it takes a reference to a model for example)

Okay, I've rewritten the API again, and I think that this is about as simple as it will get while still allowing LlamaSampler to be either a chain or a single sampler. It is also about as close to the raw api as it was before this pr. I will write documentation for the new methods on LlamaSampler later tody.